The present invention relates to an operating system of a computer, and in particular, to an operating system generation method in which input/output device control programs can be incrementally added to an operating system.
An operating system (to be abbreviated as an OS herebelow) includes a basic portion of the operating system (to be abbreviated as a kernel herebelow) serving basic functions of the operating system such as process management, memory management and input/ output device control programs (to be referred to as input/output device drivers herebelow) for controlling input/output devices connected as peripheral devices. An operating system includes only one kernel, whereas a plurality of drivers are provided in association with the respective input/output devices.
In general, as the number of input/output devices connected to the computer increases, there appears an increased number of different types of drivers. In addition, since different types of input/output devices are connected to the various computer systems for the respective users, the combination of the drivers included in the operating system varies between user systems. Consequently, a procedure is required to incorporate the driver into the operating system depending on the hardware constitution of the user system.
When a driver is incorporated into an operating system, there arises a necessity of mutual reference between the driver and the kernel of the operating system for control of the input/output devices. The mutual reference is effected through three types of operations as follows:
(1) Routine call from the kernel to the driver;
(2) Routine call from the driver to the kernel; and
(3) Reference to data from the driver to the kernel.
When a user program issues an input/output request, the kernel calls a driver routine associated with the request, which corresponds to (1) above.
On the other hand, at an execution of an input/output operation, the driver routine calls the kernel routine to effect processing which can be controlled only by the kernel, which corresponds to (2) above. In addition, the driver routine references data managed by the kernel such as an address of data and a data length of data associated with the input/ output operation, which corresponds to (3) above.
When incrementally adding a driver to the operating system, the mutual reference between the kernel and the driver is required to be enabled. In general, a source program of the kernel or the driver is described by use of a symbolic name and also in a case of the mutual reference. On the other hand, in an object program or a program in an object form at an execution, all symbolic names are required to be translated into absolute addresses. When incorporating a driver into the operating system, there arises a problem of a method to translate the symbolic names to be subjected to the mutual reference between the kernel and the driver, which is referred to as a problem of an address solution herebelow.
Heretofore, there have been employed two methods of incorporating a driver in an operating system, namely, a static link method and a dynamic link method.
FIG. 2 shows the static link method in which a driver 5 calls a routine "KSUBm" in a kernel 3. When the driver 5 is linked with an object module 1 of the kernel 3 by use of the static linkage editor 7 (which is an ordinary linkage editor, namely, "static" is added thereto only for discrimination from another prior art technology of FIG. 3), a load module 18 is generated. The contents of the load module 18 thus produced include a load module 4 of the kernel 3 and a load module 6 of the driver 5, which are however combined into an integrated load module 18 of the operating system. In the load module 18, an address (XXX) of a "KSUBm" routine 17 is inserted into a location where this routine 17 is to be called (in an operand of a CALL instruction in the driver (a) 6). As described above, according to the static link method, the address solution between the kernel and the driver is accomplished when the link edit operation is conducted. This is because that since all object modules (that is, the kernel 3 and the driver 5 are simply object modules in FIG. 2, and this notification does not imply that the kernel and the driver exist in the same module and applies to all other drawings) of the drivers requiring the kernel are linked by use of the linkage editor 7, the absolute address (XXX in the example above, which is not necessarily a physical address) of the symbolic name (KSUBm in this example) to be subjected to the mutual reference can be completely recognized by the linkage editor 7.
The dynamic link method has been described in pages 173 to 176 of the "Operating Systems" written by S. E. Madnick, J. J. Donovan and published from McGraw-Hill in 1974. Referring now to FIG. 3, the address solution of the dynamic link method will be described.
In the dynamic link method, the kernel 3 and the driver 5 are not linked into a load module by use of a dynamic linkage editor 19, namely, there are produced segments 4 and 6 which are mutually independent of each other. In FIG. 3, a portion where the driver 5 calls a routine "KSUBm" in the kernel 3 retains the symbolic name "KSUBm" is retained (in the driver 6 of FIG. 3), this is true also after the processing of the linkage editor 19 for the dynamic link is accomplished. When the symbolic name "KSUBm" is referenced during an execution of the driver 6, a linkage interruption occurs in the kernel 4. A linkage interruption processing routine 21 of the kernel 4 possesses a relation table between routines and these addresses 22 including correspondences between the routine names related to the symbolic names and addresses thereof. When the linkage interruption occurs, an address (XXX) corresponding to the routine name "KSUBm" is passed to the driver 5, which in turn calls the "KSUBm" routine 17 by use of the address (XXX).
In this fashion, according to the dynamic link method, the symbolic name is retained up to the execution so as to effect the address solution at the execution.
The method to incorporate a driver in an operating system according to the prior art technology is attended with the following problems.
In general, the kinds of input/output devices connected to a computer are desired to be changed depending on the utilization situation of the computer. For this purpose, there is required means which enables the user to incrementally add a driver to the operating system in accordance with the utilization condition of the computer.
However, in the static link method described with reference to FIG. 2, it is impossible to add a new driver to the operating system which is a load module for the following reason. That is, in this method, the linkage editor 7 translates, in the link edit operation, symbolic names subjected to the mutual reference between the kernel 3 and the driver 5 into addresses so as to generate an operating system 18 as an executable load module. In other words, it is impossible for the conventional linkage editor 7 to add a new driver to the operating system 18 in the load module format for which the address solution has already been completed so as to achieve the address solution for a symbolic name to be subjected to the mutual reference thereafter. In consequence, in order to accomplish the user's request for the addition of a driver, it is necessary to achieve the link edit operation again for the object module 1 of the kernel 3 and other drivers, or to prepare various kinds of operating systems 18 for respective combinations of the drivers. However, in general, the user cannot obtain the object module 1 of the kernel 3 and other drivers 5. Moreover, when the utilization situation of the computer in the future cannot be forecasted, the combinations of the drivers cannot be easily determined in advance.
On the other hand, according to the dynamic link method described with reference to FIG. 3, the address solution is accomplished on the symbolic names for which the mutual reference is effected between the kernel 3 and the driver 5 during the execution of the operating system 18; in consequence, it is possible to add a driver to the operating system 18. However, in order to implement this method, the following two items are essential as described above:
(1) Special compiler and linkage editor capable of generating a plurality of segments and of retaining symbolic names also after the processing.
(2) Hardware causing a linkage interruption when a symbolic name is referenced.
However, an ordinary computer is not provided with such special software and hardware, therefore the dynamic link method cannot be adopted.
As described above, in the driver incorporation method of the prior art technology, there exists a problem that a driver cannot be added to the operating system depending on the change in the kind of the input/ output device connected to the computer.